1. Prior Art
In “conventional” telephony mode (using the public switched telephone network (PSTN)), telephony operators establish bilateral agreements to extend the global coverage of the telephone service. The level of coverage achieved depends essentially on the number of agreements made. In outline, it can be considered that two categories of telecommunications operator are in existence: local and/or national operators, and global operators. The major global operators make a large number of agreements and can thus reach most existing destinations. Local operators make only a small number of agreements, including only one or two with major operators. Thus, a incumbent national operator in a developing country will make agreements with other national operators and one or two agreements with global operators in order to deliver calls to the rest of the world.
At present, most operators are migrating their PSTN networks to solutions and infrastructures that are based on the IP network. To accompany the deployment of VoIP services, the Internet engineering task force (IETF) has undertaken a large amount of standardization work. Several protocols have been specified, amongst which mention can be made of session initiation protocol (SIP), session description protocol (SDP), real-time transfer protocol (RTP), real-time transfer control protocol (RTCP), multimedia gateway control protocol (MGCP), session announcement protocol (SAP), and telephony routing over IP (TRIP, RFC3219). These protocols satisfy different requirements and in particular they incorporate call signaling and control, the exchange and control of media streams, and the exchange of call routing information.
TRIP enables interconnected ITADs to exchange all of the destinations they can reach, thereby facilitating the selection of the gateways that are the most appropriate for delivering IP telephony traffic to the PSTN. The TRIP protocol is implemented by location servers (LS) that propagate TRIP routes containing attributes that serve to describe the routes in question. The use of this particular protocol is independent of the type of signaling protocol deployed for actually setting up calls. The TRIP protocol can be used together with SIP, H.323, or any other signaling protocol. Each LS maintains a local routing database known as the telephony routing information database (TRIB). This routing database is fed with advertisements received from neighboring LSes (from another telephony domain, for example). The operation of the TRIP protocol is similar to that of the BGP protocol. Advertisements between neighboring LSes are made in the form of route update messages, referred to simply as update messages. These messages are defined by the TRIP protocol and they are exchanged between LSes in order to inform a neighboring domain about routes that are available.
Activation of the TRIP protocol between various ITADs is described with reference to FIG. 1 (for reasons of simplicity, the term “domain” is also used to denote an ITAD), each ITAD being administered by a single telephony operator. Each of these operators has one or more LSes. Each LS maintains a routing database that it feeds with advertisements received from its neighbors (situated in other domains) and from LSes in its own domain. These advertisements are updated and forwarded to other neighbors when agreements permit this.
Thus, ITAD4 14, for example, updates the advertisements received from ITAD5 15 and forwards them to ITAD3 13. It should be observed that an ITAD is not necessarily deployed on a single IP transfer domain, also referred to an AS.
From the routing point of view, an LS handles three types of route:                external routes, received from LSes situated in neighboring ITADs;        internal routes, received from LSes situated in the same ITAD; and        local routes, configured locally in each LS for injection into TRIP processes.This operation is performed either by static configuration or by redistributing information coming from other routing protocols.        
Thus, four types of TRIB are managed by an LS, as is shown in FIG. 2. These tables exist in a single LS, and the relationship between the tables are described with reference to FIG. 2.                “Adj-TRIBs-In” 22: stores routing information conveyed by update messages. This routing information, also referred to as “routes”, constitutes the input to a route selection process 21 (decision process). A given LS maintains an adjacent TRIB-In table 22 for each neighboring LS in which it stores all of the route advertisements received from an adjacent LS;        “Ext-TRIB” 24: only one external TRIB table is maintained by an LS. This table contains the results of a route selection process applied to external routes 25 (Adj-TRIBs-IN) and local routes 26. Prior art techniques enable only one route to be selected per destination;        “Loc-TRIB” 20 (“local TRIB”): this table contains the local routes that result from applying routing policies that are local to each LS; and        “Adj-TRIBs-Out” 23 (adjacent TRIBs out): these are the routes that the local LS will advertise to its peers.        
In the transfer layer (the layer that actually transfers calls), it is possible to use the QoS-enhanced border gateway protocol (q-BGP) in order to be aware of the QoS treatment to which the voice streams will be subjected.
In the present state of the prior art, there does not exist any mechanism for managing the quality of service between telephony operators on IP.
2. Drawbacks of the Prior Art
One drawback of that prior art technique is the problem of QoS not being taken into consideration at service level in existing approaches. Available offers in terms of telephony rely on the transfer layer to perform the QoS treatment that is required by the digital streams (audio and/or video) that are to be transferred.
Unfortunately, means do not exist for (dynamically) correlating the two layers (service layer for ITAD via the TRIP protocol, for example, and transfer layer for ASes, via the BGP protocol, for example). A correlation can be put into place, but it requires a static route configuration. The TRIP protocol does not define an attribute that makes it easy to achieve correlation with the “q-BGP” protocol and the QoS information propagated thereby between different border routers.
Another drawback of that prior art technique is that LSes do not have dynamic and credible means for judging the QoS associated with a given route. As a result, LSes can select paths that offer calls that do not comply with the QoS expectations of end clients and that are not optimum.